Flugzeug-Vogel-Kollisions-Schaden

Klassifikation

Team: Gisser, Bauer, Resavac

Teamrollen & Problemstellung

Rollen im Team

  • Projektleiterin: Yvonne Gisser
  • R-Experte: Roland Bauer
  • Machine-Learning-Experte: Dusan Resavac

Problemstellung

~ Vorhersage, ob die Kollision eines Flugzeugs mit Vögeln zu einem Schade führt ~

Art der Ausführung: Klassifikation

Ziele & Datengrundlage

Zielsetzung

  • Zur Evaluierung der finalen Ergebnisse werden sowohl der Recall als auch die Precision herangezogen.

  • für mehr Informationen siehe: Modell 4/4 - Metrik

Referenzdatensatz

~ FAA wildlife strike reporting program ~

Beschreibung des Datensatzes

Spalten- /
Variablenanzahl
100
1. Eintrittsdatum
1990-01-02
Flughäfenanzahl
2588

Zeilen- / Beobachtungsanzahl
279373
letztes Eintrittsdatum
2023-05-03
Flugzeuganzahl
591

Modell 1/4

Auswahl der Zielvariable

  • Überlegung: Wir möchten den Schweregrad hervorsagen
    • Lösung: Wir wählen die Variable “DAMAGE_LEVEL” als abhängige Variable / Zielvariable
      • alle anderen Variablen mit “DAM_” beginnend werden weggelassen

Modell 2/4

Beschreibung der Zielvariable



# A tibble: 6 × 2
  DAMAGE_LEVEL  count
  <chr>         <int>
1 D                81
2 M              8550
3 M?             6638
4 N            162666
5 S              4211
6 <NA>          97227

Modell 3/4

Auswahl der Prädiktoren

  • Annahme: Wir nehmen an, dass es einige Variablen gibt, die einen Einfluss auf unsere abhängige Variable haben, darunter jene mit “STR_” beginnend
    • Lösung: diese Variablen werden als unabhängige Variablen / Prädiktoren ausgewählt

Modell 4/4

Metrik

  • Recall für Klasse “D” (destroyed) soll mind. > 0.9 sein
  • Rest soll als Klasse “S” (substantial) klassifiziert werden

Wichtig:
1. Grobe Schäden dürfen nicht unerkannt bleiben
2. Die False Positive Rate darf nicht zu groß sein
=> da dies in unnötigem Wartungs- bzw. Reparatur-Aufwand resultieren würde

Weitere Modelle

  • Basismodell: häufigste Klasse von “DAMAGE_LEVEL”
    => N
  • Statisches Modell: ?
  • Dynamisches Modell: ?

    Diese Modelle machen für unseren Use Case keinen Sinn!

Projektorganisation

  • regelmäßige Team-Meetings:
    finden online auf Microsoft Teams statt
  • Dokumentation
    (inkl. Aufgabenteilung, Workflow & Meilensteinplan)
    :
    liegt auf dem GitHub Repository des Projekts
  • Verwaltung der Aufgaben:
    findet am Kanban Board des Projekts statt

Aufgabenteilung 1/2

  • Die Aufgaben werden so aufgeteilt, dass jede*r in jedem Bereich des Projekts mitwirkt. Die Rollenverteilung dient dementsprechend lediglich der Information, bei welcher Person sich bei Bedarf für den jeweiligen Bereich am schnellsten Hilfe geholt werden kann. Das Ziel besteht also darin, dass sich nach Abschluss des Projekts jedes Teammitglied in allen Projektbereichen selbstsicher fühlt.

  • Dabei wird darauf geachtet, dass für jedes Mitglied ungefähr der gleiche Arbeitsaufwand besteht - um die Fairness zu gewährleisten.

Aufgabenteilung 2/2

gemeinsame Aufgaben:
- EDA
- Quantitative Analyse
- Feature Engineering

getrennte Aufgaben:
- Model Fitting
- Model Tuning

beispielhafter Projektablauf: Wir übernehmen seine Kategorisierung der Aufgaben

Plan für die Ausarbeitung 1/2

Pipeline / Workflow

Plan für die Ausarbeitung 2/2

Zeitplan / Meilensteinplan

Backlog TBD

Beantwortung von Fragen

  • Frage unsererseits:
    Wie sollen wir die NAs unserer Zielvariable behandeln?
    • Optionen:
      1) NAs entfernen
      2) NAs Labels zuordnen => Overkill?